The present invention relates generally to the field of computers and computer systems. More particularly, the present invention relates to publish/subscribe messaging systems providing controlled distribution of messages from a source to one or more targets.
Publish/subscribe is known as an effective technique for handling of message queues. Rather than directly identifying an intended recipient for a message, the originator (publisher) publishes the message to a topic, which topic is typically identified in the message header. One or more recipients (subscribers) can then arrange to receive such messages by subscribing to the topic. A message handling or brokering stage sits between the publishers and subscribers and handles the routing of published messages to subscribers according to topic. In this way, the publisher does not need to know the identities of the various subscribers and the subscribers do not need to know the publisher providing the source of the messages.
Within the brokering stage, the identities of the topics supported are stored in a structure known as a topic tree. In one known arrangement, the topic tree is organised as a hierarchy, with the broadest grouping of topics forming the base or root level of the hierarchy, and with successive levels adding further restrictions or limitations. For example, a root level may be “Cities of the World”, with successive levels then comprising “Europe”, “United Kingdom”, and “London”. Other arrangements are possible.
U.S. Pat. No. 6,643,682 (Todd, et al.) describes an example of a publish/subscribe system that provides extended functionality through allowing the modification of message content at the broker stage, for example to apply local currency exchange rates. This is achieved by incorporating one or more message transformation subsystems within the broker, which subsystems apply a transform function to the data payload of selected messages. A disadvantage with this system is that modifying the message will result in a change of topic, which may cause housekeeping problems within the broker in terms of the integrity of the topic tree. A further disadvantage is that allowing the subscribers to subscribe to particular transforms relies on the transforms being available on the broker.
U.S. Pat. No. 7,734,723 (Bedi, et al.) is another example of a publish/subscribe system which seeks to address a first problem of U.S. Pat. No. 6,643,682, namely the modification of topics. In this instance, the publisher does not specify the topic directly, but instead sends topic data which is then processed to generate a topic within the message broker. Topic data is in the form of a function and an associated parameter list, and is associated with a message (typically, inserted in the message header) in the same way that a topic would be inserted in previous systems. Topic consistency is now provided, but the availability of transform functions is constrained as before.
A general problem of publish/subscribe systems is that, when publishing or subscribing to a message broker, the client must know explicitly which topics to publish or subscribe to. One approach to this problem is to use wildcards whereby, during subscription, there are wildcard mechanisms that can be used to subscribe to a set of topics. Wildcards provide for a simple matching mechanism to be applied to the topic tree, allowing subscription to all subtopics or the set of all topics within a topic tree. For example, using the “+” and “#” wildcards, the topic tree path definition:                /a/b/+/x/y/z        
would return the topics                /a/b/c/x/y/z        /a/b/d/x/y/z        /a/b/e/x/y/z        
and so on, whilst the path definition                /a/b/c/#        
would return                /a/b/c/d        /a/b/c/d/e        /a/b/c/f        
and so on.
Wildcards are, by their nature, a coarse tool that will often generate unwanted results in addition to what is required. Also, it will be understood that this option is restricted to subscribing: there is no equivalent option for publishers.
An alternative approach is to control message flows. Defined as a sequence of processing steps that run in the broker when an input message is received, message flows are managed on the server side—that is to say, a client would need broker administrative access to define, change, or remove a message flow definition. This is not a simple matter and the facility is generally not available to clients.